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Database fragmentation 

• Similar problem to « disk fragmentation » 

• Data spread all over disk sectors 

• Dramatically increases I/O count 
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OSM-FR main tile server 



July 2014 : close to 100 % I/O bandwidth used 

- SSD could not keep up with tile rendering request 
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Disk utilization for /dev/sdb - from Sat Jul 19 12:37:11 2014 to Thu Aug 21 12:37:11 2014 




Close to 100 % I/O usage 



Mon Wed Fri 
Device utilization 




Sun Tue Thu Sat Mon Wed 



Avg: Max: 
27. 69 99. 99 

Last update: Thu Aug 21 12:35:11 2014 
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How does Postgres store data ? 

• 8 KB at a time... these are postgres « pages » 

• A page is filled with data until it is full 

• No default mechanism to gather data on the 
same page 
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How does mapnik uses data ? 



• Objects located in a given bbox are needed to 
render one (meta) tile 

• These objets are usually store in many different 
postgres 8KB pages 

• Many pages to access in order to get all objects 
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Let's optimize this ! 

• Make sure nearby objects are stored on the 
8KB pages 

• Fewer pages will have to be read from disk to 
access the same objets 
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Postgres CLUSTER ! 



• Postgres CLUSTER command allows to reorder 
data based on one index 



• CLUSTER makes a copy of the data using the 
index 

- 1st step : CREATE INDEX 

- 2nd step : CLUSTER 
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Which index ? 



• PostGIS geometric index is not optimal 

- Creates « rectangle » based indexes 

- Our tiles are more « square » than « rectangles » 
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Geohash to the rescue ! 

• Geohash are a text version of close to square 
bounding boxes 

• Longer geohash = smaller boxes 

• Postgis inclused ST_Geohash function ! 

Check geohash on wikipedia for more details. . . 
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Which geohash length ? 

• Zoom 18 tiles = 2 A 18 

• Zoom 18 metatiles = 2 A 15 

• Each geohash char adds 2.5 bits 

• 15 / 2.5 = 6^6 chars are enough ! 

• Helps limit index size (has hash computation) 
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Optimizing index creation 



ST_Geohash needs WGS84 input data... 
For nodes (easy) : 

• ST_Geohash(ST_Transform(node,4326),6) 

CREATE INDEX p lane t_osm_point_c luster 
planet_osm_point 

( ST_Geohash ( ST_Transform(way, 4 32 6 ) ,6) ) 
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Optimizing index creation 



For ways (and polygons) : 

• ST_Geohash(ST_Transform(way,4326),6) 

- ST_Transform computes each node WGS84 
location !!! 

• ST_Expand(way,0) - get the way bbox, then compute 
Geohash 

CREATE INDEX planet_osm_line_c luster ON 
planet_osm_line 

(ST_Geohash(ST_Trans form (ST_Expand( way, 0 ) ,4326) , 6 ) ) ; 
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Let's CLUSTER ! 

Traps : 

• locks may occur during the CLUSTER (suspend diff updates!) 

• CLUSTER is making a full copy of the data and needs disk space 
for that 

• it may take a long time... several hours for the planet_osm_polygon 
table in my case 

CLUSTER planet_osm_point USING planet_osm_point_c luster ; 
CLUSTER planet_osm_roads USING planet_osm_roads_c luster ; 
CLUSTER planet_osm_line USING planet_osm_line_c luster ; 
CLUSTER planet_osm_polygon USING planet_osm_polygon_cluster ; 
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I/O reduced ? 
100 % down to 15 % ! 



Check the stats again... 
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Disk utilization for/dev/sdb - from Sat Jul 19 12:37:11 2014 to Thu Aug 21 12:37:11 2014 



n 



Mon Wed Fri 
Device utilization 



i 



Before CLUSTERING 
close to 100 % I/O usage 



After CLUSTERING 
around 15 % I/O usage 



Sun 




Avg: Max: 
27. S9 99. 99 

Last update: Thu Aug 21 12:35:11 2014 



SOTM-2014 Buenos-Aires 



(Positive) Side effects... 

• Useful data density increase in data pages 

• Less data pages to read from disk to render a 
given metatile 

• Disk cache can hold more useful data in RAM 
-+ Even less disk I/O ! 
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On the long term 



• CLUSTER reorganize data on disk only at the 
time it is used 

• New and updated data will not respect the 
CLUSTER ordering 

Need to re-CLUSTER from time to time... 
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Time to re-CLUSTER ? 



• I/O increasing after a few months of update... 



Disk utilization for /dev/sdc - from Sat Oct 5 04:22:13 2013 to Sun Nov 9 03:22:13 2014 

100 




Cur: Hin: Avg: Max: 

■ Device utilization 26.26 0.00 43.49 100.18 

Last update: Sun Nov 9 03: 25: 10 2014 

Munin 2.0.6-*+dd 
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Questions ? 



Christian Quest 
OSM : cquest / twitter : @cq94 
Email : cquest@openstreetmap.fr 
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